Field of the Invention
The present invention relates to the field of Network portals and in particular to a method and system for restricting access rights on user profile information using a new notion of peer groups.
Description and Disadvantage of Prior Art
In this field the term “composite application” defines an application hosted on a web portal platform which is built by combining and connecting multiple components such as portlets, wikis, document libraries and web services, for a particular purpose such as a shop or a virtual team room application. A single portal platform may host multiple instances of the same composite application, for example different team rooms for different associated user communities. Composite applications are built from a template describing the contained components and their set-up and interconnection.
FIG. 1 shows the overview of the components that build up the prior art application infrastructure 11—abbreviated herein also as AI—system architecture within an overall portal system 10. The application infrastructure comprises:                the templating application infrastructure 13—abbreviated herein also as TAI—that handles the templates in the system and the creation of new composite applications,        the composite application infrastructure 15—abbreviated herein also as CAI—that handles the application instances 19 during runtime and manages connections and the data flow between the components of an application,        the component registry 27 that manages the business components installed in the system, and        the portal handler 29 which is a specific local component that manages any portal related artifacts 8 like pages or portlets for the application infrastructure in the portal, and which is used by the instantiation component 17 to create such artifacts during the creation of a new composite application.        
The templating application infrastructure (TAI) component 13 manages the templates 23 in the system which contain references to instantiable components in a local list of components 27. As an example, a template for shopping applications could consist of a reference to a document library component which is used to hold the available goods and their descriptions, a shop portlet that let clients process actual shopping transactions, an invoice business component that handles the payment process and a blogging component that allows clients to comment on their satisfaction.
The TAI component 13 also creates application instances from the templates via an instantiation component 17, which creates separate instances of the referenced business components, typically by creating or copying individual configurations for these components such that multiple application instances can be created from the same template without interfering with each other.
For the above mentioned sample template, the instantiation 17 would, among other things, create an individual storage compartment in the document library, an individual configuration of the invoice component referring to the bank account and an individual configuration for the shop portlet that is set up to display goods from the created document library and to delegate payment processing to the created invoice component instance.
In particular, the instantiation 17 needs to create the necessary portal artifacts like pages that allow to interact with the created composite application, which is typically done by employing a specific handler 29 that creates those portal artifacts 8 and links them with the business components of the application.
The created composite application instances 19 hold a context 25 that lists the component instances that make up the composite application
FIG. 2 shows an overview of the storage components involved in the portal architecture 10 that comprises deployment related code in a deployment component 14 and a runtime environment in one or more runtime containers 12 where the deployed components are executed.
For the composite application context deployed artifacts are:                application components stored in a component registry 18,        templates stored in a template catalog 20.This data is then referenced by the application's instance specific data 16.        
With reference now to the focus of the invention, prior art composite applications are a key concept of prior art Service Oriented Architecture. They allow end-users to assemble business logic out of a set of given components without programming by simply defining some meta information, such as configuration data and application structure.
Prior art composite applications are supported for example by the prior art IBM WebSphere Portal and other known products.
With reference now to FIG. 3, 4, 5A 5B, and with respect to the very technical problem of the current invention, prior art web-based collaboration platforms typically support the concept of “communities”. A community 50 (e.g., circle 50 in FIG. 5A) is a set of people—e.g. persons D, E F, that share a specific working objective or interest. Being member of a given community typically comes with access to resources or portal objects 8 (FIG. 1) shared within the community such as documents, portal pages, and portlets 32, in order to be able to collaborate together in one or more composite applications. Other communities 51 and 52 coexist with similar function and persons contained therein.
Communities in prior art are created and managed in a dynamic on-demand fashion with the creator of a community being the community manager that is allowed to invite other people to the community. This disadvantageously includes much manual work.
With particular reference to FIG. 3, in prior art collaboration platforms, access control on user data is typically managed by a logical program component 36 in a way orthogonal to the community concept. This means, a security administrator defines by way of a logical User Management program component 34, which user is allowed to see profile information of what other users. Based on this access control information, users can benefit from people awareness features, like “who is online right now . . . ”. Details thereto are explained with reference to FIG. 4.
With particular reference to FIG. 4 illustrating prior art access management to users for a certain given single user, when this single user initiates a search on an other user, see step 1 in FIG. 4, this user uses a respective user interface for such search request which is provided by some portlet 41 to him. This portlet 41 passes his request to the user management component 34, which intern provides the access to a user data store and a group data store, see step 2.
Then in a further step 3 an interaction step between component 34 and access control component 36 is performed during which it is checked if the before mentioned user “Bob” is allowed to see other users. The respective control information is managed by the access control component 36 which stores and manages access information on all types of resources, and so also of the resource “user”.
In order to do that the access control component 36 looks up the access rights for user Bob in its current configuration, see step 4.
In order to do that completely, also the static access information from database 39 is looked up by observing the entry for user Bob. The result is returned to the user management component 34 which evaluates this result and sends the search request to a backend storage device 38, for example the LDAP user store in order to perform search overall available users.
Further disadvantageously, and with respect to step 5 in FIG. 4, there is no dynamic method available to allow an “admin” user concerned with security management tasks, to restrict the available user base of a given user to the persons he has a need to collaborate to. If something like this is required the admin will need to manage the access rights for every user, if a membership of a community has changed, which results in a high personal manual effort of the admin.
Further, prior art collaboration tools only allow each user to search all users from the available directory. This is of great disadvantage however, as in many situations the full list of users—e.g.—several hundred or several thousands of them is simply too large to be scrolled and controlled by an individual.
Thus, the desire results that a name is able to be made invisible for others. The only way to be “invisible” for other users, however, is by either using a black or a white list. Those lists, however, need to be maintained by each individual user, however, which again results in a high personal manual effort.